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Abstract 

Hybrid systems are characterized by the hybrid 
evolution of their state: A part of the state changes 
discretely, the other part changes continuously over 
time. Typically, modern control applications be- 
long to this class of systems, where a digital con- 
troller interacts with a physical environment. In 
this article we illustrate how a combination of the 
formal method VDM and the computer algebra sys- 
tem Mathematica can be used to model and simu- 
late both aspects: the control logic and the physics 
involved. A new Mathematica package emulating 
VDM-SL has been developed that allows the in- 
tegration of differential equation systems into for- 
mal specifications. The SAFER example from [TT] 
serves to demonstrate the new simulation capabili- 
ties Mathematica adds: After the thruster selection 
process, the astronaut's actual position and veloc- 
ity is calculated by numerically solving Euler's and 
Newton's equations for rotation and translation. 
Furthermore, interactive validation is supported by 
a graphical user interface and data animation. 

1 Introduction 

Modern control applications are realized through 
microcontrollers executing rather complex control 
logics. This complexity is increased by the fact that 
control software interacts with a physical environ- 
ment through actors and sensors. Such systems are 
called hybrid systems due to the hybrid evolution of 
their state: One part of the state (variables) changes 
discretely, the other part changes continuously over 
time. 

Hybrid systems are excellent examples for moti- 
vating the use of formal software development meth- 
ods. First, their complexity calls for a real soft- 
ware engineering discipline applying both, a pro- 



cess model as well as a mathematical method. Sec- 
ond, these kinds of systems are often safety-critical 
which justifies formal validation and verification 
techniques. Third, engineers in the control domain 
are educated in the use of mathematical models for 
designing dynamic systems. 1 In our experience, the 
offer of a formal method for software development 
is more often appreciated by control engineers, than 
by software developers used to produce short cycle 
products in 'Internet time'. 

In the hybrid system SAFER has been cho- 
sen by NASA in order to introduce to formal spec- 
ification and verification techniques. SAFER is 
an acronym for "Simplified Aid For EVA (Ex- 
travehicular Activity) Rescue" . It is a small, 
lightweight propulsive backpack system designed to 
provide self-rescue capabilities to a NASA space 
crewmember separated during an EVA. In this 
NASA guidebook[H]. SAFER is specified formally 
in the PVS notation and properties are formally 
proved using the PVS theorem prover In the 
guidebook the dynamic aspects are used to com- 
pare the continuous domain model from spacecraft 
attitude control with the discrete PVS model of 
SAFER's control logic. It demonstrates that the 
two models have the same goals: rigorous descrip- 
tion and prediction of behavior but that the needed 
mathematics and calculation techniques are differ- 
ent. 

In J! [2] Agerholm & Larsen have proposed 
a cheaper testing based validation approach to 
the SAFER example using an executable VDM-SL 
model and the IFAD VDM-SL Toolbox [HI El El- 
They recommend the use of a specification executor 
and animator for raising the confidence in a formal 
model prior to formal proving. 

We agree with Agerholm & Larsen's arguments 
for such a "light-weight" approach to formal meth- 

1 The same holds for software developers coming from clas- 
sical engineering disciplines. 



ods in order to facilitate the technology transfer. 
Since in several industrial projects performed at 
our institute a similar experience has been made 
[UlEDEli one of our research areas has become the 
support of testing through formal methods @]. 

However, neither the PVS nor the VDM-SL 
model of SAFER did take the continuous physical 
models into account. The reason is that, in gen- 
eral, today's formal method tools are not well suited 
for supporting continuous mathematics. This paper 
shows a solution the problem. 

In the following it is demonstrated how an ex- 
plicit discrete model can be combined with the con- 
tinuous physical model for validation and anima- 
tion. With the right tool there is no reason why a 
physical model should not be included in the valida- 
tion process of a hybrid system. Just the opposite 
is the case: pp detected several cases where the in- 
terface to a cut out automatic attitude hold (AAH) 
control unit needed further clarification. 

In this work the commercial computer algebra 
system Mathematica has been used to overcome 
the gap between discrete and continuous mathemat- 
ics. A VDM-SL package has been implemented that 
allows to specify in the style of the Vienna Develop- 
ment Method (VDM) inside Mathematica. Thus, 
explicit discrete models can be tested in combi- 
nation with differential equation systems modeling 
physical behavior by solving the equations on the 
fly Even pre- and post-condition checking is pos- 
sible. Again, NASA's SAFER system serves as the 
demonstrating example. The VDM-SL specification 
of 2 has been taken and extended with the physics 
involved in SAFER, expressed through differential 
equations. More precisely, the physical behavior is 
movement in space, modeled by the laws for transla- 
tion and rotation — Newton's and Euler's equations 
for three dimensional space. 

Beside the execution (testing) of hybrid models, 
Mathematica's front-end supports the visual valida- 
tion of such systems. The graphical user-interface 
for SAFER's hand grip is implemented inside the 
computer algebra system as well as a scientific graph 
representing the movement of a crew-member using 
SAFER. After each control cycle, actual physical 
vectors like angular velocity or acceleration can be 
inspected together with the logical status, e.g. the 
thrusters firing. Finally, it is even possible to an- 
imate a sequence of performed control-cycles as a 
movie showing the SAFER representation flying. 

The structure of the rest of the paper is as fol- 
lows. First in Section [3 an overview of the SAFER 
system is given, which will serve as the demonstrat- 
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Figure 1. SAFER thrusters. 



ing example throughout the paper. This is followed 
by a discussion of VDM-SL and its realization in- 
side Mathematica in Section [3] Then, a description 
of the discrete SAFER model is given in Section 

01 Section [SI explains the differential equation sys- 
tems modeling SAFER's physics and the coordinate 
transformations needed. Then, Section[S]introduces 
to the hybrid model and demonstrates the integra- 
tion of VDM-SL and differential equation systems. 
Next, the validation capabilities of our approach are 
discussed in Section and Section |H1 In the final 
Section |5| we draw some conclusion regarding the 
presented work in particular, as well as possible fu- 
ture approaches in general. 

2 The SAFER System 

The following overview of the SAFER system is 
based on, and partly copied from, the NASA guide- 
book which describes a cut-down version of a 
real SAFER system. 

The Simplified Aid for EVA Rescue (SAFER) is 
a small, self-contained, backpack propulsion system 
enabling free-flying mobility for a NASA crewmem- 
ber engaged in extravehicular activity (EVA). It is 
intended for self-rescuing on Space Shuttle missions, 
as well as during Space Station construction and op- 
eration, in case a crewmember got separated from 
the shuttle or station during an EVA. This type of 
contingency can arise if a safety tether breaks, or 
if it is not correctly fastened. SAFER attaches to 
the underside of the Extravehicular Mobility Unit 



(EMU) primary life support subsystem backpack 
and is controlled by a single hand controller that 
is attached to the EMU display and control mod- 
ule. Figurenshows the backpack propulsion system 
with the 24 gaseous-nitrogen (GN2) thrusters, four 
in each of the positive and negative X, Y and Z 
directions. For example, the thrusters denoted by 
5-F1, 6-F2, 7-F3 and 8-F4 are firing backwards (indi- 
cated by the arrows) resulting in a forward motion. 

The main focus of the discrete specification is 
on the thruster selection logic, which is rather com- 
plex due to a required priorization of hand controller 
commands. Various display units and switches 
which are not directly related to the selection of the 
thrusters have been ignored in our model. However, 
in contrast to and the calculation of the con- 
trol output in the Automatic Attitude Hold (AAH) 
is not ignored, but simulated based on a dynamic 
model of the physics discussed in Section [5] 




Figure 2. Hand controller module of 
SAFER. 



The hand controller, shown in Figure is a 
four-axis mechanism with three rotary axes and one 
transverse axis using a certain hand controller grip. 
A command is generated by moving the grip from 
the center null position to mechanical hard-stops 
on the hand controller axes. Commands are ter- 
minated by returning the grip to the center po- 
sition. The hand controller can operate in two 
modes, selected via a switch, either in translation 
mode, where X (forward-backwards), Y (left-right), 
Z (up-down) and pitch commands are available, or 
in rotation mode, where roll, pitch, yaw and X 
commands are available. The arrows in Figure 
show the rotation mode commands. Note that X 
and pitch commands are available in both modes. 



Pitch commands are issued by twisting the hand 
grip around its transverse axis, while the other com- 
mands are obtained around the rotary axis. 

A push-button switch on top of the grip initiates 
and terminates AAH according to a certain proto- 
col. If the button is pushed down once the AAH is 
initiated, while the AAH is deactivated if the button 
is pushed twice within 0.5 seconds. 

As mentioned above there are various priorities 
among commands that make the thruster selec- 
tion logic rather complicated. Translational com- 
mands issued from the hand controller are priori- 
tized, providing acceleration along a single transla- 
tional axis, with the priority X first, Y second, and 
Z third. When rotation and translation commands 
are present simultaneously from the hand controller, 
rotations take higher priority and translations are 
suppressed. Moreover, rotational commands from 
the hand grip take priority over control output from 
the AAH, and the corresponding rotation axes of 
the AAH remain off until the AAH is reinitialized. 
However, if hand grip rotations are present at the 
time when the AAH is initiated, the corresponding 
hand controller axes are subsequently ignored, until 
the AAH is deactivated. 

In pP it is explained how a specification inter- 
preter tool facilitates the validation of the require- 
ments listed in the appendix of the NASA guide- 
book. Moreover, it is demonstrated that formal val- 
idation techniques uncover open issues in informal 
requirements even if they seem to be straightfor- 
ward and clear. 

The same validation techniques as discussed in 
PP can be applied in our Mathematica based frame- 
work — and more. However, before we discuss the 
value added through a hybrid model, in the follow- 
ing section, the realization of our VDM-SL package 
is discussed. 

3 VDM-SL in Mathematica 

VDM-SL is the specification language of the Vi- 
enna Development Method (VDM) [THl El - VDM 
is a widely used formal method, and it can be ap- 
plied to the construction of a large variety of sys- 
tems. It is a model-oriented method, i.e. its for- 
mal descriptions (specifications) consist of an ex- 
plicit model of the system being constructed. More 
precisely mathematical objects like sets, sequences 
and finite mappings (maps) are used to model a 
system's global state. Additional logic constraints, 
called data-invariants, allow one to model informal 
requirements by further restricting specified data- 



types. For validation purposes the functionality 
may be specified explicitly in an executable subset 
of VDM-SL. In addition, pre- and post-conditions 
state what must hold before and after the evalua- 
tion of a system's operation. Although VDM-SL 
is called a general purpose specification language it 
does not support the specification of dynamic sys- 
tems. The language's ISO-standard J3| does not 
even include standard functions like sine or cosine. 

Here, as the name indicates, Mathematica's 
strengths supplement our combined approach. 
Mathematica is a symbolic algebra system that of- 
fers the opportunity of solving arbitrary non-linear 
as well as linear systems of equations. Mathemat- 
ica's language interpreter is in fact a rewriting sys- 
tem providing an untyped functional programming 
language. For an introduction to functional pro- 
gramming in Mathematica see This program- 
ming language has been used in order to define a 
package emulating the specification language VDM- 
SL. By emulating we express the fact that the pack- 
age does not allow one to write specifications in 
VDM-SL's concrete syntax, but in its abstract syn- 
tax with some pretty printing for VDM-SL output. 

Mathematica's user interface are so called note- 
books, fancy editors structured in cells for input, 
output or plain text. Entering a Mathematica ex- 
pression in an input cell, the system tries to evaluate 
this input through a rewriting procedure based on 
pattern matching. 

The following language constructs have been 
added to the standard language in order to import 
the VDM-SL model from 

• abstract datatypes for composite types, sets, 
sequences and maps 

• comprehension expressions for sets, sequences 
and maps 

• let and cases expressions 

• operators for propositional and predicate logic 

• types optionally restricted by data-invariants 

• value and global state definitions 

• typed function/operation definitions with pre- 
and post-conditions 

Some of the items above deserve a more detailed 
discussion. 



Comprehensions 

A powerful feature of a specification language 
like VDM-SL is its ability to construct collection 
types like sets, sequences and maps through com- 
prehensions. For example, a set-comprehension de- 
fines a set through an arbitrary expression describ- 
ing the set-elements with its free variables ranging 
over a set of values, such that an optional condi- 
tion holds. The following example demonstrates 
the value added through a computer algebra sys- 
tem. The set-comprehension 

set[x|{x £ 1} ■ {x 6 - 44x 5 + 318x 4 + 4102x 3 

-4461x 2 + 550x + 8750 == 0}] 

represents a set of elements x, where x is an integer 
number such that the equation holds. 
The resulting set 2 

set[-7, -1, 25] 

demonstrates that, unlike IFAD's VDM-SL inter- 
preter, comprehensions ranging over infinite sets 
may be evaluated. 

Types 

As already mentioned, in contrast to VDM, 
Mathematica has an untyped language. Conse- 
quently, no type checking mechanism is available. 
However, types are an important tool for specifying 
a data-model in VDM. Therefore, type declarations 
of the form Type [name, type] have been included, 
where type is one of the predefined VDM-SL types, 
like basic types, composite types, sets ... For exam- 
ple, a type ISet representing a set of natural num- 
bers might be declared by Type[lSet, set[N]]. 

Optionally, a type can be further constrained by 
a data-invariant condition. Such invariant types 
are defined by Type[name, type, Invariant— > 
predicate]. The predicate is defined by a lambda 
expression mapping type to a Boolean value. All 
the invariants are globally stored in the system for 
invariant checking, before and after the evaluation 
of a VDM function. 

Internally, a type is translated to a Mathematica 
pattern, matching those values the type denotes. 
Invariant types are supported by the possibility of 
defining patterns with arbitrary predicates. These 
patterns restrict the argument range in the defini- 
tion of typed VDM functions. 

2 The six solutions including double and complex solutions 
are: -7,-1,1 - 1,1 + 1,25,25. 



VDMFunction[ 

SelectedThrusters , 

AUX'SixDof Command X AUX ' RotCommand X 
set [AUX' Rot Axis] X set [AUX 'Rot Axis] 
-> ThrusterSet, 
SelectedThrusters [hem, aah, actAxes, ignHcm] := 
let[{tran, rot, bf Mandatory, bf Optional , 

lrudMandatory , lrudOpt ional , bf Thr , lrudThr} , 
{tran, rot} = 

(IntegratedCommands [hem, aah, actAxes , ignHcm] 
/ . SixDof Command [tr_ , ro_] : ->tr , ro) ; 
{bfMandatory, bfDptional} = BFThrusters [tran [X] , 

rot [PITCH] , 
rot [YAW] ] ; 

{lrudMandatory, lrudOptional} = 

LRUDThrusters[tran[Y] , 
tran[Z] , 
rot [ROLL] ] ; 

bfThr = If [(rot [ROLL] === ZERO), 

bfOptional U bfMandatory, 
bfMandatory ] ; 
lrudThr = If [(rot [PITCH] === ZERO) and 
(rot [YAW] === ZERO) , 
lrudOptional U lrudMandatory, 
lrudMandatory] ; 
set 89 (bfThr U lrudThr) 
] 

] ; 



Functions 

Using the VDM-SL package, typed functions 
with pre- and post-conditions can be defined using 
the constructor 

VDMFunctiontid, sig, id[vars] := body, pre, post] 

with the following parameters: 

id the name of the function, 

sig the signature of the function, 

id [vars] : = body the function definition, 

pre an optional pre-condition stating what must 
hold before the evaluation such that the post- 
condition holds, 

post an optional post-condition stating what must 
hold after the evaluation. 

VDMFunction realizes a complex call to Mathemat- 
ica's internal Function call and emulates the checks 
for 

• the signature types, 

• pre- and post-condition, 

• data-invariants. 

4 Discrete Model 

In order to demonstrate the Mathematica pack- 
age the same functions for the thruster selection 
logic as in ^ are presented in this section. The 
six degree-of-freedom of the translation and rota- 
tion commands is modeled using a composite type: 

Type [SixDof Command, Composite [{ "tran" , TranCommand} , 

{"rot", RotCommand }]] 

whose two fields are finite maps from translation 
and rotation axis respectively to axis commands. 
For example the type of translation commands is 
defined as follows: 

Type [TranCommand , TranAxis -> Axiscommand, 
Invariant -> (dom[#] == set [X,Y,Z]&)] 

where the invariant ensures that command maps 
are total. Here, the invariant predicate is defined 
by a lambda expression in Mathematica's notation 
of pure functions. The type of rotation commands 
is defined similarly. Enumerated types are used for 
axis commands and translation and rotation axes: 



Figure 3. The SelectedThrusters function. 

Type[AxisCommand, NEG I ZERO I POS] ; 

Type [TranAxis , X I Y I Z] ; 

Type [Rot Axis, ROLL I PITCH I YAW] 

In the SelectedThrusters function in Fig- 
ure |21 grip commands from the hand controller 
(with six-degree-of freedom commands) are in- 
tegrated with the AAH control output. The 
IntegratedCommands function prioritizes hand con- 
troller and AAH commands. 

Based on these commands, thrusters for back and 
forward accelerations and left, right, up and down 
accelerations are calculated by two separate func- 
tions. Figure 01 presents cut-down versions of these 
functions. These represent a kind of look-up ta- 
bles, modeled using cases expressions. Note that 
they return two sets of thruster names, represent- 
ing mandatory and optional settings respectively. 

5 Physics Involved in SAFER 

This section presents the continuous model of 
the physics involved in our hybrid model. For the 
SAFER example, translation and rotation equations 
from mechanics are sufficient for modeling the mo- 
tion of a crewmember using the propulsion system. 
The purpose of this model is twofold: First, we need 
to calculate the sensor inputs of angular velocity for 
simulating the AAH. Second, in order to visualize 



VDMFunction[ 
BFThrusters , 

AUX'AxisCommand X AUX ' AxisCommand X AUX'AxisCommand 
-> ThrusterSet X ThrusterSet , 
BFThrusters [A , B, C] := 
cases[{A, B, C} , 

{NEG, ZERO, ZERO} -> {{B4}, {B2.B3}}, 
{ZERO, ZERO, ZERO} -> {{}, {}}, 
{POS, NEG , ZERO} -> {{F1.F2}, {}}, 

] 

] ; 

VDMFunction[ 
LRUDThrusters , 

AUX'AxisCommand X AUX'AxisCommand X AUX'AxisCommand 
-> ThrusterSet X ThrusterSet, 
LRUDThrusters [A, B, C] := 
cases[{A, B, C} , 

{NEG, NEG, ZERO} -> {{}, {}}, 

{NEG, ZERO, ZERO} -> {{L1R.L3R}, {L1F.L3F}}, 

{POS, ZERO, POS} -> {{R2R}, {R2F.R4F}}, 

] 

] ; 



Figure 4. Extracts from BFThrusters and 
LRUDThrusters. 



the SAFER movement, absolute coordinates have 
to be determined. The mathematics needed can be 
found in the standard literature of mechanics, like 

Translation 

The translation of a crewmember wearing 
SAFER is described by Newton's second law of mo- 
tion expressed by 

F = mil = p (1) 

where F, m, v and p denote force vector, mass, 
velocity vector and impulse vector. It states that 
"The time rate of change of the momentum of a 
particle is proportional to the force applied to the 
particle and in the direction of the force." 



tions arc then given by 
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or as a vector equation where / is a diagonal matrix: 

i -ii + n x I -fl = Q (5) 

Qi denotes a torque causing a rotation around the 
i-axis, in the body's own coordinate system. Here, 
the torque is given by the sum over the thrusters fir- 
ing. Actually, a component Q th is calculated by the 
cross product of a thruster's position vector relative 
to the center of mass and its force. SAFER does not 
use proportional gas jets, but thrusters whose valves 
are open or not, which simplifies the calculation. 

Motion 

In order to combine translation and rotation in a 
single model of motion, suitable for our purposes, 
coordinate transformations are necessary. More 
precisely, the fixed coordinate system values for vi- 
sualization (position and velocity) have to be related 
to SAFER's coordinate system values (angular ve- 
locity). 

As fi is calculated in the body's own coordinate 
system, they have to be transformed back to the 
fixed coordinate system. Given the Eulcr angles <p, 
9 and tp that denote the deviation of the fixed x, y 
and z axis, the angular velocities can be calculated 
according to the following formula. 

fli = ip sin 9 sin + 9 cos 4> (6) 
Sl 2 = <p sin 9 cos — sin -0 (7) 
fi 3 = (p cos 9 + tjj (8) 

The derivation of these equations can be found in 
Using vector notation we get the equation: 

Q = D 3 (ip) ■ Dx(9) ■ (9,0,cp) T + (0,0,^) T (9) 



Rotation 

The rotation is modeled by three equations 
known as the Euler's equations of motion for the 
rotation of a rigid body. 

Denote by fl the angular velocity defined with re- 
spect to the center of mass, and by / the moments 
of inertia. The equations describing the body rota- 
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where D\ and D% are rotation matrices that turn 
the coordinate system by a given angle. 



VDMFunction[ 
ControlCycle , 

SwitchPositions X HandGripPosition X 

Rot Command X InertialRef Sensors -> ThrusterSet, 

ControlCycle [SwitchPositions [mode_ , aah_] , rawGrip , 
aahCmd, IRUSensors] := 

let[{ 

gripCmd=HCM £ GripCommand[rawGrip, mode] , 
thrusters=SelectedThrusters [gripCmd, aahCmd, 
AAH £ ActiveAxes [] , AAH ' IgnoreHcm [] ] 

}. 

AAH'Transition[IRUSensors, aah, gripCmd, SAFER'clock] ; 
SAFER' clock=SAFER £ clock+1 ; 
PosData=CalcNewPosition [thrusters] ; 
thrusters 

] , 

True, 

card [RESULT] < 4 A ThrusterConsistency [RESULT] 

] ; 

VDMFunction[ 

SensorControlCycle , 

SwitchPositions X HandGripPosition -> ThrusterSet, 

SensorControlCycle [SwitchPositions [mode_ , aah_] , 
rawGrip] : = 

ControlCycle [SwitchPositions [mode, aah] , rawGrip, 
AAHControlOut [Sensors] , Sensors ] 

] ; 



D\ and D3 are used to transform a vector from 
our fixed coordinate system to a turned coordinate 
system. For translation motion, the thruster's force 
vector F has to be transformed from SAFER's coor- 
dinate system to the fixed one using the transposed 
rotation matrices: 

(D 3 (ip) ■ Dx(6) ■ D 3 (tf)) T 

Summarizing, these four vector differential equa- 
tions are sufficient for modeling SAFER's motion 
over time: 

v = x (12) 
m'V=(D 3 (il>)-Di(p)-Ds(<p)) T F (13) 

i -n + n x 1 fi = q (14) 

n = D 3 (ip) ■ D x (9) ■ (9,0,<pf + (0,0, ^) T (15) 

Solving these equations with given thruster forces 
results in SAFER's position vector x(t) and the an- 
gular velocity Q(t) used for AAH. 

Alternatives to the Euler's equations model are 
possible. For example, an aproach could have in- 
volved the less computationally intensive quater- 
nions. However, for validation purposes the model 
should be as intuitive as possible, here efficiency 
plays a minor role. 

6 A Hybrid Model 

The hybrid model of SAFER consists of the hand 
controller and the Automatic Attitude Hold as its 
discrete parts on one side and the equations of mo- 
tion as the continuous part on the other side. Both 
are modeled in Mathematica, the first in the form of 
the VDM-SL specification using our VDM-SL em- 
ulation package, the later in the form of ordinary 
differential equations in Mathematica notation. 

The combination of the discrete control system 
and the continuous physical model during the test- 
ing phase carries certain advantages: 

Not only can the system specification be tested 
in an (idealized) physical simulation, but also the 
system parameters like the force of the thrusters and 
the moments of inertia of the backpack can easily be 
adjusted until the system responds in a way suitable 
for practical use. 

This is not a very rigorous approach, and it is not 
intended to replace other testing tools and meth- 
ods. Rather it can serve as a valuable supplemen- 
tary tool. 



Figure 5. The ControlCycle function. 

The Control Cycle 

The ControlCycle function (FigureEJ) integrates 
the discrete model of hand control, thruster se- 
lection and Automatic Attitude Hold (AAH) with 
the continuous physical model of motion presented 
above. 

The Control Cycle is implemented in two differ- 
ent functions. ControlCycle takes the state of the 
hand control (switches and hand grip) as well as the 
already calculated or manually entered AAH com- 
mands and the sensor values. SensorControlCycle 
takes the values of the sensors (here simulated by 
the solutions of the equations of motion of the pre- 
vious control cycle) and determines which thrusters 
are invoked by the AAH. These are then passed on 
to ControlCycle. 

After determining the active thrusters and the 
AAH state, the differential equations are solved nu- 
merically in the CalcNewPosition function and the 
current position is updated. These results simulate 
the values measured by the sensors (with exception 
of the heat sensors, which are left out in our model) 
providing data for AAH. This part of the control 
system is completely left out in and only included 
in the form of two unspecified functions in the PVS 
model jllj . 

Here the SAFER state is not as trivial as in pQ 
where it holds only a clock variable. 



VDMFunction[ 
AAHControlOut , 

Inert ialRef Sensors->RotCommand, 

AAHControlOut [IRUSensors] := 

let [{rr=IRUSensors . "RollRate" , 

pr=IRUSensors . "PitchRate" , 
yr=IRUSensors . "YawRate"}, 

map [ 

ROLL->Which[ 

rr < -EpsRoll,POS, 
rr > EpsRoll, NEG, 
True , ZERO] , 

]] 

] ; 



Figure 6. The Bang Bang algorithm for 
AAH. 



State [SAFER, 

Type [clock, N] , 

Type [PosData, PositionData] , 

Type [Sensors , InertialRef Sensors] , 

Type [step, Rpos] , 

Type [PosDataList , List [PositionData] ] , 

init [SAFER] := SAFER [0, 

PositionData [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 

InertialRef Sensors [0, 0, 0, 0, 0, 0, 0, 0, 0], 

1/4, {{{0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}}}] 

] ; 

The state above also includes the current posi- 
tion, Euler angles and velocities stored in a variable 
of type PositionData. 

Even the past position data is stored for provid- 
ing full information about SAFER's trajectory. For 
simulation this data will be used to display the his- 
tory as a Mathematica "movie" showing the astro- 
naut flying around in the coordinate system. 

Automatic Attitude Hold (AAH) 

Simulating the measured sensor values by the re- 
sults of the equations of motion provides the op- 
portunity of including the Automatic Attitude Hold 
mechanism by a simple Bang Bang algorithm: If 
the angular velocity for an axis where AAH is turned 
on exceeds a certain threshold, selected thrusters 
are fired in order to slow down this rotation (Fig- 
ure [SJ). AAH is limited to this mechanism because 
SAFER is only based on simple thrusters with two 
states: on and off. 

The Differential Equations 

The equations of motion used to determine the 
new position of the astronaut are Newton's and 
Euler's equations described above. Although this 



model neglects any gravitational forces and other 
disturbing influences, they could easily be added by 
an additional acceleration in the equations or ran- 
dom fluctuations applied to the results of the differ- 
ential equations. 

The new position is obtained by numerically solv- 
ing the equations rather than algebraically which is 
less time-efficient, beside the fact that the algebraic 
solution is not necessary as only the result at time 
step is needed for simulation. 

Since the equations are only slightly coupled, 
they can be solved in four steps, which is numeri- 
cally more stable than solving them all at once. This 
functionality is provided by Mathematica's NDSolve 
function, which takes the differential equations and 
the initial conditions and returns numeric functions 
that approximate the exact solutions of the equa- 
tions. In this case the trajectory is calculated piece- 
wise: in every control cycle the trajectory only for 
that cycle is solved using the position before the cy- 
cle as the initial conditions and the force and torque 
applied by the thrusters as parameters. These can 
easily be calculated, the force by a simple vector ad- 
dition of the forces applied by every single thruster, 
and the torque by adding up the cross products of 
the thruster positions with the force applied by that 
thruster. 

First, Euler's equation in the astronaut's coor- 
dinate system is solved giving the angular velocity. 
This needs the forces and the torque applied by the 
fired thrusters as parameters. The result is then 
transformed back to the fixed coordinate system 
and used to solve the differential equation for the 
Euler angles. In a third step Newton's equation can 
be solved using the results from the previous equa- 
tions. Finally, a simple integration of the velocities 
gives the position of the astronaut. 

These numerical solutions to the differential 
equations can also be used to investigate stability. 
In the simplified case without any external forces 
like gravitation, this might not be so interesting, 
but as soon as external forces are modeled into the 
differential equations, stability is a crucial concern. 
What happens if the hand controller keeps in the 
same position over a long period of time? Such 
questions can easily be answered by solving the dif- 
ferential equations for a time period longer than just 
the control cycle. 

7 Simulating SAFER 

Mathematica does not only provide algebraic and 
numeric functionality, but also an extensive reper- 



toire of plotting functions. Thus Mathcmatica has 
also been used to visualize SAFER's current posi- 
tion together with other state information. 
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Figure 7. The GUI for the hand controller. 

An interface to the hand controller similar to that 
in [5] is provided in Mathematica (Figure 0) . It 
contains buttons for all the hand controller states 
as well as for manual input of the AAH output for 
overriding the simulated AAH in the model. 

Pressing one of the buttons sets a global variable 
that is used to determine the parameters passed to 
the ControlCycle function. Additionally, the "Cy- 
cles=l" button determines how many control cycles 
should be evaluated when the "Run Control Cycle" 
button is pressed. 

Pressing "Run Control Cycle" initiates the con- 
trol cycle and after calculating the new position 
prints out a plot of the astronaut's path so far to- 
gether with his orientation indicated by the axes of 
his own coordinate system (Figure|Hl). Additionally, 
his velocity and angular velocity are shown as vec- 
tors. Optionally a table with the list of the fired 
thrusters as well as the axes where AAH is turned 
on is printed. 

Since all the previous position data is stored, 
Mathematica can even animate this graph so that 
one can inspect the SAFER moving through space. 

A graphical interface to the simulation like in 
Figure0is interesting when testing the system's be- 
havior in general. However, when adjusting param- 
eters or testing specific cases, it's more convenient 
to run the control cycles directly using Mathemat- 
ica input commands. Figure shows the input to 
create Figure 

In pQ the visualization is done outside the 
toolbox using dynamic link modules, which are 
programmed specifically for this one application. 
In Mathematica, changing only the differential 
equations suffices to include other influences like 



Figure 8. A sample trajectory of the 
SAFER. 



gravity, as Mathematica chooses the algorithm to 
solve the equations. 

However, testing in Mathematica is not restricted 
to graphical simulation. Like in 1 , the output of 
the thruster selection logic can be validated by enu- 
merating all possible states of the Hand controller, 
or in an extended version enumerating all possible 
states of the hand controller and the AAH. Fig- 
ure EH shows these functions formulated in Math- 
ematical VDM-SL notation. On every possible 
state, ControlCycle is applied to calculate the fired 
thrusters. The result of this large map comprehen- 
sion then has to be investigated manually. 

Another important part in the process of veri- 
fying software would be coverage testing, which is 
unfortunately not possible in Mathematica. 

8 Enhanced Analysis of the System 

The simulation possibilities described in the last 
section can be exploited for risk and safety analysis 
of the system. A very simple application is the case 
when one of the thrusters fails due to a mechanical 
defect or an iced valve. The most important ques- 
tions in this scenario are whether the astronaut will 
still be able to navigate the system, and whether it 
is possible to return before the air or the nitrogen 
for the thrusters is used up. 

We investigated the functionality of AAH in the 
case where one thruster (6-F2) fails. Figure ITTI 
shows the angular velocity of the system, with the 



ResetSAFERPosition[ ]; 
(* 1 right *) 

Do [SensorControlCycle [SwitchPositions [TRAN,UP] , 
HandGripPosition [ZERO , ZERO ,PQS , ZERO] ] ,{1}] ; 
C* 3 yaw *) 

Do [SensorControlCycle [SwitchPositions [ROT, UP] , 

HandGripPosition [ZERO, ZERO, POS, ZERO]] ,{3}] ; 
(* 15 "right" *) 

Do [SensorControlCycle [SwitchPositions [TRAN, UP] , 

HandGripPosition [ZERO, ZERO, POS, ZERO]] ,{15}] ; 
C* wait *) 

Do [SensorControlCycle [SwitchPositions [TRAN, UP] , 
HandGripPosition [ZERO, ZERO, POS, ZERO]] ,{2}] ; 
(* 3 up *) 

Do [SensorControlCycle [SwitchPositions [TRAN, UP] , 
HandGripPosition [POS, ZERO, ZERO, ZERO]] ,{3}] ; 
C* 6 down *) 

Do [SensorControlCycle [SwitchPositions [TRAN, UP] , 
HandGripPosition[NEG, ZERO, ZERO, ZERO]] ,{6}] ; 
(* 5 up *) 

Do [SensorControlCycle [SwitchPositions [TRAN, UP] , 
HandGripPosition [POS, ZERO, ZERO, ZERO]] ,{5}] ; 

C* nothing, just keep floating in space *) 

Do [SensorControlCycle [SwitchPositions [TRAN, UP] , 
HandGripPosition [ZERO, ZERO, ZERO, ZERO]] ,{6}] ; 

C* finally, 2 down *) 

Do [SensorControlCycle [SwitchPositions [TRAN, UP] , 
HandGripPosition [NEG, ZERO, ZERO, ZERO]] ,{2}] ; 



Figure 9. The commands to create the sam- 
ple trajectory. 



hand grip set to forward acceleration. Just be- 
fore cycle 4 is initiated, thruster 6-F2 breaks, which 
would be used in this acceleration. This leaves 
thruster 7-F3 applying an additional torque to the 
system, which results in an increasing angular ve- 
locity. In cycles 9 and 10 the astronaut initiates 
AAH, but keeps the forward acceleration (cycles 10 
to 17 and 20 to 25). AAH is now only able to com- 
pensate the additional torque, but not to reduce the 
angular velocity. Only when the forward accelera- 
tion is turned off (cycles 17 to 20 and 25 to 30), 
AAH shows effect. 

The functionality of AAH could be improved by 
immediately excluding thruster 7-F3 from the trans- 
lational commands when thruster 6-F2 fails (and 
thus allowing thruster 3-B3 to be used by AAH in- 
stead of 6-F2). This would require a slightly modi- 
fied and more complex thruster selection logic, pro- 
viding a higher level of safety for the astronaut. 

9 Concluding Remarks 

In this article a hybrid model of NASA's SAFER 
system has been presented using the specification 
language VDM-SL inside the computer algebra sys- 
tem Mathematica. We demonstrated that the im- 
plementation of a VDM-SL package for Mathemat- 
ica provides both, VDM-SL's powerful language fea- 



VDMFunction[ ControlCycleTest , 

SwitchPositions X HandGripPosition X RotCommand -> 
ThrusterSet , 

ControlCycleTest [SwitchPositions [mode_ , aah_] , rawGrip, 
aahCmd] : = 

SelectedThrusters [HCM'GripCommand [rawGrip , mode] , 
aahCmd, AAH' ActiveAxes [] , AAH' IgnoreHcm [] ] , 
True, 

card [RESULT] < 4 A ThrusterConsistency [RESULT] 

] ; 

VDMFunction[ BigTest, 

{}->(HCM'SwitchPositions X HCM'HandGripPosition X 

AUXIL' RotCommand -> ThrusterSet), 
BigTest[]:= map [ C {switch, grip, aahLaw}-> 
ControlCycleTest [switch, grip, aahLaw] ) I 
{switchE SwitchPositions , gripGgripPositions , 
aahLawGallRotCommands }] 

] 

VDMFunction[ HugeTest, 

{}->(HCM'SwitchPositions X HCM'HandGripPosition X 

AUXIL 'RotCommand -> ThrusterSet), 
HugeTest[]:= map[({switch, grip, aahLaw}-> 
ControlCycleTest [switch, grip, aahLaw] ) I 
{switchGswitchPositions , gripGallGripPositions , 
aahLawGallRot Commands}] 

] ; 



Figure 10. The testing functions. 

tures, like comprehensions, as well as the mathemat- 
ical power of Mathematica, e.g. solving differential 
equation systems. 

The SAFER example shows the validation pos- 
sibilities of such a combined tool. Like in pQ the 
complex discrete model of the control logic can be 
validated through testing. This is a cheap technique 
for raising the confidence that the right model has 
been specified prior to the application of more ex- 
pensive formal proof techniques. 

However, with the right tool, there is no rea- 
son why the continuous models of a hybrid system 
should be excluded from validation. Such a hybrid 
validation is more suitable for finding unjustified do- 
main assumptions made in the discrete model. We 
strongly propose such validations, due to the fact 
that making wrong assumptions is the weak point 
of formal verification techniques, possibly leading to 
correct proofs of the wrong model. 

Furthermore, we demonstrated that the visual- 
ization features of Mathematica provide a conve- 
nient way to communicate a model to a customer. 
Moreover, in contrast to [Q, our visualization is a 
functional graph that facilitates the communication 
to control experts as well as to customers with a 
technical expertise. 

In the Irish school of VDM, Mathematica has 
been used to explore explicit VDM specifications 
[Tl| , but to our present knowledge not for modeling 
hybrid systems. 
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Figure 11. Angular velocity with a broken 
thruster, AAH initiated in cycle 9. 



Note that the conclusion of our work is not that 
Mathematica is the best tool for validating hybrid 
system specifications. Our Mathematica approach 
has its disadvantages, too: Our VDM-SL represen- 
tation is not as readable as the notation of standard 
VDM-SL and a typed language would be more suit- 
able for specification purposes. Rather than propos- 
ing a certain tool, our work points out the features 
a powerful toolset should provide for validating hy- 
brid systems. 

Another future approach would be the integra- 
tion of a classic formal method tool with a com- 
puter algebra system. For example a combination 
of Mathematica with the IFAD VDM-SL Toolbox 
used in yQ would be a possibility. This could be re- 
alized with the lately developed CORBA API of this 
tool, that enables access to the toolbox as a CORBA 
object and thus calling its VDM-SL interpreter from 
programs implemented in C or Java. Mathematica 
provides an interface through its MathLink facility. 

Summarizing, we feel that our approach of hy- 
brid validation is a valuable technique for produc- 
ing systems of higher reliability and hope that it will 
stimulate further research in this area. 

Acknowledgment 

Many thanks to William Milam from the Ford 
Motor Company. At the FME'96 conference, he 
pointed the first author to the industrial needs of an- 
alytical methods and tools for hybrid systems. Pe- 
ter Gorm Larsen and Peter Lucas were kind enough 
to comment on a draft of this paper for which we 
are very thankful. Finally, the authors would like 
to thank the four anonymous referees for the inter- 



esting comments and suggestions. 
References 

[1] Sten Agerholm and Peter Gorm Larsen. 
Modeling and validating SAFER in 
VDM-SL. In Proceedings of the Fourth 
NASA Langley Formal Methods Work- 

shop (Lfm97). NASA, September 1997. 

http : //shemesh. larc .nasa.gov/fm/Lfm97/proceedings/ 

[2] Sten Agerholm and Peter Gorm Larsen. 
SAFER specification in VDM-SL. 
Technical report, IFAD, September 
1997. VDM Examples Repository: 

http: //www. if ad.dk/Products/VDMTools/vdmsl-examples 

[3] Bcrnhard K. Aichernig. Teaching programming 
to the uninitiated using Mathematica. Techni- 
cal Report IST-TEC-98-03, Institute for Soft- 
ware Technology, TU-Graz, Austria, May 1998. 

[4] Bcrnhard K. Aichernig. Automated black- 
box testing with abstract VDM oracles. In 
M. Felici, K. Kanoun, and A. Pasquini, editors, 
Computer Safety, Reliability and Security: pro- 
ceedings of the 18th International Conference, 
SAFECOMP'99, Toulouse, France, September 
1999, volume 1698 of Lecture Notes in Com- 
puter Science, pages 250-259. Springer, 1999. 

[5] Georg Droschl. Events and scenarios in VDM 
and PVS. In 3rd Irish Workshop in For- 
mal Methods, Galway, Electronic Workshops in 
Computing. Springer- Verlag, July 1999. 

[G] John Fitzgerald. Information on VDM. VDM: 
http : / / www . csr . newcastle . ac . uk/vdm/ 

[7] John Fitzgerald and Peter Gorm Larsen. Mod- 
elling Sytems, Practical Tools and Techniques. 
Cambridge University Press, 1998. 

[8] Walter Hauser. Introduction to the Principles 
of Mechanics. Addison- Wesley, 1965. 

[9] Johann Horl and Bernhard K. Aichernig. 
Formal specification of a voice communica- 
tion system used in air traffic control, an 
industrial application of light-weight for- 
mal methods using VDM++ (abstract). In 
J.M. Wing, J. Woodcock, and J. Davies, 
editors, Proceedings of FM'99 - Formal 
Methods, World Congress on Formal Methods 
in the Development of Computing Systems, 
Toulouse, France, September 1999, volume 



1709 of Lecture Notes in Computer Sci- 
ence, page 1868. Springer, 1999. Full report at 

ftp : //ftp . ist .tu-graz . ac . at/pub/publications/IST-TEC-99-03 .ps . gz 

[10] Cliff B. Jones. Systematic Software Develop- 
ment Using VDM. Prentice-Hall International, 
Englewood Cliffs, New Jersey, second edition, 
1990. 

[11] John C. Kelly and Kathryn Kemp. Formal 
methods, specification and verification guide- 
book for software and computer systems, vol- 
ume II: A practitioner's companion, planning 
and technology insertion. Technical Report 
NASA-GB-001-97, NASA, Washington, DC 
20546, May 1997. 

[12] SRI Computer Science Laboratory. The PVS 
specification and verification system. PVS: 
http : //pvs . csl . sri . com/ 

[13] P. G. Larsen, B. S. Hansen, H. Bruun, 
N. Plat, H. Toetenel, D. J. Andrews, J. Dawes, 
G. Parkin, et al. Information technology — 
Programming languages, their environments 
and system software interfaces — Vienna De- 
velopment Method — Specification Language 
— Part 1: Base language, December 1996. In- 
ternational Standard ISO/IEC 13817-1. 

[14] Colman Reilly. Exploring specifications with 
Mathematica. In Proceedings of the Z User 
Workshop, Department of Computer Science, 
Trinity College, Dublin, 1995. 

[15] Rudi Schlatte and Bernhard K. Aichernig. 
Database development of a work-flow planning 
and tracking system using VDM-SL. In John 
Fitzgerald and Peter Gorm Larsen, editors, 
Workshop Materials: VDM in Practice!, Part 
of the FM'99 World Congress on Formal Meth- 
ods, Toulouse, September 1999. 

[16] Stephen Wolfram. The Mathematica Book. 
Wolfram Media/Cambridge University Press, 
3rd edition, 1996. 



